前言
这篇文章主要分析一下dispatch_once的底层实现,相对而言,这应该是GCD源码分析系列中最简单的一篇了。
dispatch_once分析
在iOS开发中,我们经常使用dispatch_once去定义一个单例,来保证对象的唯一性,不过我们是否去了解过dispatch_once是如何在多线程情况下保证生成对象的唯一性呢?例如,我们经常用下面的代码块生成一个单例。1
2
3
4
5
6
7
8+ (instancetype)sharedInstance {
static XXObject *_instance;
static dispatch_once_t _predicate;
dispatch_once(&_predicate, ^{
_instance = [[XXObject alloc] init];
});
return _instance;
}
这段代码中涉及到两个关键词,一个是dispatch_once_t
,一个是dispatch_once
,下面我们逐个分析
dispatch_once_t
在once.h中找到其定义如下:1
typedef long dispatch_once_t;
dispatch_once_t原来是一个长整型!真是让人措手不及…
dispatch_once
1 | void dispatch_once(dispatch_once_t *val, void (^block)(void)){ |
可以看到,在dispatch_once
中,生成一个Block_basic指针,指向了block,并把其Block_invoke函数指针传递给了dispatch_once_f
相信大家一定有疑问,Block_basic
和Block_invoke
是什么东西?很遗憾,源码中找不到,我们可以推测一下:
Block_basic
首先是一个结构体,它定义的指针可以指向void (^block)(void)
类型的block
Block_invoke
的字面意思是触发一个block
,可以参考以下代码理解
1 | void _dispatch_call_block_and_release(void *block) |
接下来分析核心函数dispatch_once_f
:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17void dispatch_once_f(dispatch_once_t *val, void *ctxt, void (*func)(void *)){
volatile long *vval = val;
if (dispatch_atomic_cmpxchg(val, 0l, 1l)) {
func(ctxt); // block真正执行
dispatch_atomic_barrier();
*val = ~0l;
}
else
{
do
{
_dispatch_hardware_pause();
} while (*vval != ~0l);
dispatch_atomic_barrier();
}
}
1、在开篇中已经讲过
dispatch_atomic_cmpxchg
,它是一个宏定义,原型为__sync_bool_compare_and_swap((p), (o), (n))
,这是LockFree给予CAS的一种原子操作机制,原理就是 如果p==o,那么将p设置为n,然后返回true;否则,不做任何处理返回false2、在多线程环境中,如果某一个线程A首次进入
dispatch_once_f
,*val==0,这个时候直接将其原子操作设为1,然后执行传入dispatch_once_f
的block,然后调用dispatch_atomic_barrier
,最后将*val的值修改为~0。3、
dispatch_atomic_barrier
是一种内存屏障,所谓内存屏障,从处理器角度来说,是用来串行化读写操作的,从软件角度来讲,就是用来解决顺序一致性问题的。编译器不是要打乱代码执行顺序吗,处理器不是要乱序执行吗,你插入一个内存屏障,就相当于告诉编译器,屏障前后的指令顺序不能颠倒,告诉处理器,只有等屏障前的指令执行完了,屏障后的指令才能开始执行。所以这里dispatch_atomic_barrier
能保证只有在block执行完毕后才能修改*val的值。4、在首个线程A执行block的过程中,如果其它的线程也进入
dispatch_once_f
,那么这个时候if的原子判断一定是返回false,于是走到了else分支,于是执行了do~while循环,其中调用了_dispatch_hardware_pause
,这有助于提高性能和节省CPU耗电,pause就像nop,干的事情就是延迟空等的事情。直到首个线程已经将block执行完毕且将*val修改为~0,调用dispatch_atomic_barrier
后退出。这么看来其它的线程是无法执行block的,这就保证了在dispatch_once_f
的block的执行的唯一性,生成的单例也是唯一的。
dispatch_once死锁(更新模块)
上面说了这么多,是不是说使用dispatch_once
写单例就可以高枕无忧了呢?
实际上并非如此,不正当地使用dispatch_once
可能会造成死锁:
死锁方式1:
1、某线程T1()调用单例A,且为应用生命周期内首次调用,需要使用dispatch_once(&token, block())初始化单例。
2、上述block()中的某个函数调用了dispatch_sync_safe,同步在T2线程执行代码
3、T2线程正在执行的某个函数需要调用到单例A,将会再次调用dispatch_once。
4、这样T1线程在等block执行完毕,它在等待T2线程执行完毕,而T2线程在等待T1线程的dispatch_once执行完毕,造成了相互等待,故而死锁死锁方式2:
1、某线程T1()调用单例A,且为应用生命周期内首次调用,需要使用dispatch_once(&token, block())初始化单例;
2、block中可能掉用到了B流程,B流程又调用了C流程,C流程可能调用到了单例A,将会再次调用dispatch_once;
3、这样又造成了相互等待。
所以在使用写单例时要注意:
- 1、初始化要尽量简单,不要太复杂;
- 2、尽量能保持自给自足,减少对别的模块或者类的依赖;
- 3、单例尽量考虑使用场景,不要随意实现单例,否则这些单例一旦初始化就会一直占着资源不能释放,造成大量的资源浪费。
dispatch_once写单例的省力姿势
1 |
|
然后在要实现的单例.h文件中添加singleton_h,.m文件中添加singleton_m即可
总结
dispatch_once
的分析是最简单的,这也意味着后续系列的的分析将逐渐变得复杂,等待猛烈的暴风雨吧!